home *** CD-ROM | disk | FTP | other *** search
/ Amiga Plus 1995 #1 / Amiga Plus 1995 #1.iso / animationen / retina_fli_ii / fli.new.format next >
Text File  |  1994-12-13  |  8KB  |  203 lines
  1.  
  2. From: kdarling@hobbes.ncsu.edu (Kevin Darling)
  3. Newsgroups: comp.graphics
  4. Subject: Re: FLI file-format?
  5. Message-ID: <1991Mar12.202026.5005@ncsu.edu>
  6. Date: 12 Mar 91 20:20:26 GMT
  7. Organization: North Carolina State University
  8.  
  9. >Has someone a description of the FLI-format?
  10.  
  11. Autodesk Animator files explanation (.FLI only excerpted).  I believe
  12. that the original programmer wrote up this doc.  It's correct, as I've
  13. used the info to realtime playback stock .FLIs on a 680x0 machine.
  14. All numbers in a .FLI file are in Intel format, so you may have to
  15. compensate for that, of course. - kevin
  16.  
  17. 8.1 Flic Files (.FLI)
  18.  
  19.      The details of a FLI file are moderately complex, but the
  20. idea behind it is simple: don't bother storing the parts of a
  21. frame that are the same as the last frame.  Not only does this
  22. save space, but it's very quick.  It's faster to leave a pixel
  23. alone than to set it.
  24.  
  25.      A FLI file has a 128-byte header followed by a sequence of
  26. frames. The first frame is compressed using a bytewise run-length
  27. compression scheme.  Subsequent frames are stored as the
  28. difference from the previous frame.  (Occasionally the first
  29. frame and/or subsequent frames are uncompressed.)  There is one
  30. extra frame at the end of a FLI which contains the difference
  31. between the last frame and the first frame.
  32.  
  33.      The FLI header:
  34.  
  35.      byte size name      meaning
  36.      offset
  37.  
  38.      0    4    size      Length of file, for programs that want
  39.                          to read the FLI all at once if possible.
  40.      4    2    magic     Set to hex AF11.  Please use another
  41.                          value here if you change format (even to
  42.                          a different resolution) so Autodesk
  43.                          Animator won't crash trying to read it.
  44.                          New format: magic = AF12.
  45.      6    2    frames    Number of frames in FLI.  FLI files have
  46.                          a maxium length of 4000 frames. New format (?)
  47.      8    2    width     Screen width (Old: 320, New: Any).
  48.      10   2    height    Screen height (Old: 200, New: Any).
  49.      12
  50.      14   2    flags     Must be 0.
  51.      16   2    speed     Number of video ticks between frames.
  52.                          Old: 1/70th of a second.
  53.                          New: 1/1000th of a second.
  54.      18   4    next      Set to 0.
  55.      22   4    frit      Set to 0.
  56.      26   102  expand    All zeroes -- for future enhancement.
  57.  
  58. Note: In some files there is a bunch of extra bytes here.  Programs should
  59.       should scan byte by byte until they find the frame header.
  60.  
  61.      Next are the frames, each of which has a header:
  62.  
  63.      byte size name      meaning
  64.      offset
  65.      0    4    size      Bytes in this frame.  Autodesk Animator
  66.                          demands that this be less than 64K. (Not in new)
  67.      4    2    magic     Always hexadecimal F1FA
  68.      6    2    chunks    Number of 'chunks' in frame.
  69.      8    8    expand    Space for future enhancements. All zeros.
  70.  
  71.      After the frame header come the chunks that make up the
  72. frame.  First comes a color chunk if the color map has changed
  73. from the last frame.  Then comes a pixel chunk if the pixels have
  74. changed.  If the frame is absolutely identical to the last frame
  75. there will be no chunks at all.
  76.  
  77.      A chunk itself has a header, followed by the data.  The
  78. chunk header is:
  79.  
  80.      byte size name meaning
  81.      offset
  82.      0    4    size Bytes in this chunk.
  83.      4    2    type Type of chunk (see below).
  84.  
  85.      There are currently five types of chunks you'll see in a FLI
  86. file:
  87.  
  88.      number    name      meaning
  89.      11        FLI_COLOR Compressed color map (6 bit)
  90.      12        FLI_LC    Line compressed -- the most common type
  91.                          of compression for any but the first
  92.                          frame.  Describes the pixel difference
  93.                          from the previous frame.
  94.      13        FLI_BLACK Set whole screen to color 0 (only occurs
  95.                          on the first frame).
  96.      15        FLI_BRUN  Bytewise run-length compression -- first
  97.                          frame only
  98.      16        FLI_COPY  Indicates uncompressed 64000 bytes soon
  99.                          to follow.  For those times when
  100.                          compression just doesn't work!
  101.       4        FLI_NEWCOLOR
  102.                          New format.  Compressed color map (8 bit)
  103.       7        FLI_NEWLC New format.  Word-length line compressed.
  104.  
  105.      The compression schemes are all byte-oriented.  If the
  106. compressed data ends up being an odd length a single pad byte is
  107. inserted so that the FLI_COPY's always start at an even address
  108. for faster DMA.
  109.  
  110. FLI_COLOR Chunks
  111.  
  112.      The first word is the number of packets in this chunk. This
  113. is followed directly by the packets.  The first byte of a packet
  114. says how many colors to skip.  The next byte says how many colors
  115. to change.  If this byte is zero it is interpreted to mean 256. 
  116. Next follows 3 bytes for each color to change (one each for red,
  117. green and blue).
  118.  
  119. FLI_NEWCOLOR Chunks
  120.  
  121.      Exactly the same as FLI_COLOR, except for a slight difference.
  122. FLI_COLOR stores a six-bit palette, right aligned.  FLI_NEWCOLOR uses
  123. a full eight-bit palette.
  124.  
  125. FLI_LC Chunks
  126.  
  127.      This is the most common, and alas, most complex chunk.   The
  128. first word (16 bits) is the number of lines starting from the top
  129. of the screen that are the same as the previous frame. (For
  130. example, if there is motion only on the bottom line of screen
  131. you'd have a 199 here.)  The next word is the number of lines
  132. that do change.  Next there is the data for the changing lines
  133. themselves.  Each line is compressed individually; among other
  134. things this makes it much easier to play back the FLI at a
  135. reduced size.
  136.  
  137.      The first byte of a compressed line is the number of packets
  138. in this line.  If the line is unchanged from the last frame this 
  139. is zero.  The format of an individual packet is:
  140.  
  141.  skip_count
  142.  size_count
  143.  data
  144.  
  145.      The skip count is a single byte.  If more than 255 pixels
  146. are to be skipped it must be broken into 2 packets. The size
  147. count is also a byte.  If it is positive, that many bytes of data
  148. follow and are to be copied to the screen.  If it's negative a
  149. single byte follows, and is repeated -size_count times.
  150.  
  151.      In the worst case a FLI_LC frame can be about 70K.  If it
  152. comes out to be 60000 bytes or more Autodesk Animator decides
  153. compression isn't worthwhile and saves the frame as FLI_COPY.
  154.  
  155. FLI_NEWLC Chunks
  156.  
  157.      This is similar to FLI_LC, with a few differences.  It always
  158. begins with the first line.  The first word is the number of lines
  159. that have changed.  Each line begins with a word containing the
  160. number of packets for that line.  If it is negative, then -number
  161. lines should be skipped.  The packets are similar to FLI_LC,
  162. except the data is words instead of bytes.  Skip_count is still
  163. in bytes.
  164.  
  165. FLI_BLACK Chunks
  166.  
  167.      These are very simple.  There is no data associated with
  168. them at all. In fact they are only generated for the first frame
  169. in Autodesk Animator after the user selects NEW under the FLIC menu.
  170.  
  171. FLI_BRUN Chunks
  172.  
  173.      These are much like FLI_LC chunks without the skips.  They
  174. start immediately with the data for the first line, and go line-
  175. by-line from there.  The first byte contains the number of
  176. packets in that line.  The format for a packet is:
  177.  
  178.  size_count
  179.  data
  180.  
  181.      If size_count is positive the data consists of a single byte
  182. which is repeated size_count times. If size_count is negative
  183. there are -size_count bytes of data which are copied to the
  184. screen. In Autodesk Animator if the "compressed" data shows signs
  185. of exceeding 60000 bytes the frame is stored as FLI_COPY instead.
  186.  
  187. FLI_COPY Chunks
  188.  
  189.      These are 64000 bytes of data for direct reading onto the
  190. screen.
  191.  
  192.  -eof-
  193.  
  194. Notes: Since these are animations, the last frame will delta into a
  195. copy of the first one (which was usually a large BRUN chunk).  Therefore,
  196. looping should go back to the _second_ frame chunk (usually a LC
  197. or COLOR chunk) instead of all the way back to the file beginning, to
  198. avoid a "stutter" caused by unnecessarily redecoding the original frame.
  199. Also, a very few files may have palette animation, so write your code
  200. so that COLOR chunks can be found at any time.  - kevin
  201.  
  202.  
  203.